* fix(ci): add concurrency groups so the Actions queue can drain

The repository's Actions queue is saturated and not draining: 285 runs
queued, the oldest sitting unstarted for ~24 minutes with only 2 runs
in progress. Pushes to `main` are affected as well as PRs, so no PR can
reach a green CI gate and nothing is mergeable.

Cause: 17 of 30 workflows carried no `concurrency:` block, including the
heaviest and most-triggered ones (ci, codeql-analysis, security,
e2e-tests, pr-checks, auto-label, dependency-review). #1447 correctly
removed their base-branch filters so every PR runs the gate, but without
a concurrency group each push stacks a brand-new full run beside the runs
it obsoletes. With ~30 workflows and dozens of open PRs the arrival rate
exceeds the drain rate and the backlog grows without bound.

Add a concurrency group to the 14 workflows that trigger on
pull_request, pull_request_target, push, or issues:

- Group is keyed on the PR number where one exists, falling back to
  github.ref. Keying on github.ref alone would be wrong for the
  pull_request_target workflows (pr-checks, dependabot-auto-merge),
  where github.ref resolves to the base branch and every PR would
  collide into a single group and cancel its siblings.
- cancel-in-progress is true only for pull_request and
  pull_request_target events. Push and schedule runs queue rather than
  cancel, so each merged commit keeps its own verdict instead of being
  cancelled by the next merge.
- auto-label triggers on both PRs and issues, so its key falls through
  pull_request.number -> issue.number -> github.ref.

Left untouched: bulk-issue-processor, real-processing, and stale, which
are workflow_dispatch- or schedule-only and are not queue pressure.
Group names are prefixed by workflow slug and do not collide with the
existing groups in coverage, secret-scan, pr-governance, verification,
phase-goal-tracker, or the gh-aw lock files.

This changes scheduling only. No job, step, trigger, or permission is
modified; all 28 workflow files still parse.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FoRdXUHXgtt3U6HiHdcosV

* fix(ci): key non-PR concurrency by SHA so merge bursts keep their verdicts

Self-review correction to the previous commit, plus the same fix applied
to two workflows that already had the defect.

The previous commit keyed every group on
`github.event.pull_request.number || github.ref` and set
`cancel-in-progress` false for push events, on the reasoning that push
runs would queue rather than cancel and so "each merged commit keeps its
own verdict". That claim is wrong.

`cancel-in-progress: false` prevents a new run from cancelling a
*running* one. It does not prevent GitHub from cancelling a *pending*
one: when a run is queued into a group that already has one in progress
and one pending, the pending run is cancelled. Because `github.ref` is
`refs/heads/main` for every merge, all main pushes shared one group, so
a burst of merges -- exactly what this repository does, ten in twenty
minutes -- would have silently dropped the middle commits' verdicts.
That is a quieter version of the failure being fixed.

Key non-PR runs on `github.sha` instead. Each push and scheduled run then
lands in its own singleton group and can neither cancel nor be cancelled.
This costs nothing: every `push:` trigger in these workflows is already
filtered to `main` (verified across all 13), so pushes to PR branches
fire no push runs at all and all queue pressure comes from
`pull_request`/`pull_request_target` events, which still cancel their
predecessors by PR number. The conditional `cancel-in-progress` is kept
as a second, explicit safeguard.

Also apply the same key to coverage.yml and secret-scan.yml. Both
predate this change and both carried the bare `github.ref` group with
`cancel-in-progress: true` -- the more aggressive form of the same bug,
where a merge to main cancels the previous merge's coverage and secret
scan outright. Leaving them as-is while documenting the hazard in
fourteen other files would have been incoherent.

Issue-triggered workflows (auto-assign, issue-triage, auto-label) keep
their `github.event.issue.number` key; `github.sha` is meaningless for
issues events and would collide every issue into one group.

Scheduling only. No job, step, trigger, or permission changed; all 28
workflow files parse.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FoRdXUHXgtt3U6HiHdcosV

* fix(ci): key dependabot-auto-merge check_suite runs by head SHA

Review finding from the Vercel review bot on #1510, confirmed and applied.

dependabot-auto-merge is the one workflow here that triggers on
check_suite, and on that event GITHUB_SHA is the tip of the default
branch rather than the commit under test. It is therefore identical for
every PR, so the `|| github.sha` fallback collapsed all concurrent
check-suite runs into a single group. Since cancel-in-progress is false
for that event, they would not cancel a running peer -- but GitHub still
cancels the *pending* run in a group, so one PR's merge-gate verdict
could be dropped by another PR's check suite arriving.

Fall back to github.event.check_suite.head_sha first, which is the PR
head and keeps the runs isolated, before github.sha.

Audited the other events reached by these groups for the same class of
degeneracy:

- issues (auto-assign, auto-label, issue-triage) already key on
  github.event.issue.number, which is unique.
- schedule (codeql-analysis, security) resolves github.sha to the default
  branch tip, which can coincide with that same workflow's push run at
  the same commit. That collision is between two runs of the same scan
  over the same tree, so collapsing them is harmless dedup rather than a
  lost verdict.

check_suite was the only real case.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FoRdXUHXgtt3U6HiHdcosV

---------

Co-authored-by: Claude <noreply@anthropic.com>